在大型專案中，一定會和他人合作開發，然而每個人 commit 的方式可能不同，就會造成整個專案管理變得很混亂。因此就需要有一套規則或模式，讓大家有一致的共識

提出了流程，也就是Git Flow、Github Flow、Gitlab Flow

Git Flow

由Vincent Driessen在 2010 年提出，是最早提出的一套流程

主要有 master、develop、hotfix、release 、 feature 這五種分支

• 長期分支（一直存在）
  • master（或 main）
  • develop
• 短期分支（用完就刪掉）
  • feature
  • release
  • hotfix

各分支的用途

• master
  • 放穩定可隨時上線的版本
  • 每次發佈版本，都會從這裡打版本號標籤
  • 例如：v1.0.0
• develop
  • 主開發分支，所有新功能都會合併回這裡
  • 要新增功能時，所有的 Feature 分支都會從這個分支切出去
• feature
  • 新增功能的時候用的分支
  • 命名方式：feature/login-page
  • 完成後會 merge 回 develop
• release
  • 當要準備發佈新版本時，從 develop 切出
  • 用來做最後的 Bug 修正 / 測試 / 文件更新
  • 完成後 merge 到 master（發佈）以及 develop（保留修正）
• hotfix
  • 緊急狀況發生時，開一個新分支修正 Bug 時使用
  • 從 master 切出，修完再合併回 master 和 develop

圖片來源：https://dev.to/truongpx396/git-flow-overview-and-common-git-commands-1odh

可以看到這個圖，主線就是develop的分支，有新功能要開發或要測試就會從這個分支切出去，做完更新再merge回來

Github Flow

後來 GitHub 提出了一個更簡化的流程，適合持續部署（CI/CD） 的專案

只有一條主要分支（main 或 master）

1. 從 main 切一個分支（例如：feature/login）
2. 開發完成後發 PR（Pull Request）
3. Code Review 通過後合併回 main
4. 自動部署（CI/CD）

特點：

• 流程簡單，快速敏捷
• 適合 小型專案 或 隨時上線 的團隊
• 沒有 develop、release，就一條 main 搞定

Gitlab Flow

融合 Git Flow + Github Flow，主要是為了支援不同的部署環境

特點：

• 支援多環境部署（很適合 SaaS、微服務）
• 比 Github Flow 更嚴謹，但比 Git Flow 更靈活

參考資料

https://ithelp.ithome.com.tw/articles/10281080

https://gitbook.tw/chapters/gitflow/why-need-git-flow

https://dev.to/truongpx396/git-flow-overview-and-common-git-commands-1odh